Expose error model sparsification to python module, update sinter decoders dict#257
Expose error model sparsification to python module, update sinter decoders dict#257noajshu wants to merge 13 commits into
Conversation
Exposes the per-shot error model sparsification functionality (added in PR 254) to the Python module and Sinter compatibility layer. Changes: - Moved the sparsify reactivate limit (M) heuristic calculation from the CLI to `TesseractConfig::get_sparsify_reactivate_limit()` in C++ core. - Added validation for sparsification parameters in decoder initialization. - Simplified CLI sparsification parameter resolution. - Bound sparsification parameters (`sparsify_errors`, `sparsify_base_degree`, `sparsify_max_degree`, `sparsify_reactivate_limit`) and the heuristic resolution method in `TesseractConfig` Python bindings. - Extended `TesseractSinterDecoder` to support sparsification config, maintaining pickling/serialization compatibility for distributed Sinter runs. - Registered new sparsified decoders in Sinter decoders dictionary: `tesseract-long-beam-sparsify3`, `tesseract-long-beam-sparsify2`, `tesseract-short-beam-sparsify3`, and `tesseract-short-beam-sparsify2`. - Added comprehensive Python unit tests for core sparsify config, validation, and Sinter end-to-end decoding. - Fixed pre-existing CMake build failure under strict compilers by upgrading external HiGHS dependency to v1.14.0. TAG=agy CONV=365755ec-6af0-4d9c-a7e2-4a363289b763
Added recommendations for setting K in various code types.
mhucka
left a comment
There was a problem hiding this comment.
I'm not qualified to evaluate the algorithmic or theoretical correctness, but I tried to look at this from the a basic code perspective. I had a couple of minor items, noted in-line.
In addition, one thing that I don't see (and this may just be due to ignorance of Tesseract Decoder) is an update to the .pyi files. This PR does seem to introduce new properties on some objects, which suggests the .pyi files may become out of date. Not 100% sure – just flagging it for your attention.
| `tesseract-short-beam-sparsify3`, and `tesseract-short-beam-sparsify2`. | ||
|
|
||
| As a quick rule of thumb, use the non-sparsified decoders as the safest baseline. Use `sparsify2` | ||
| for surface-code-like or mostly graphlike DEMs, and use `sparsify3` for color-code, |
There was a problem hiding this comment.
super nit: wdyt about using a name like sparsify-surface-code-like instead of sparcify2? I know it becomes longer which is not the best but something more descriptive might be good.
There was a problem hiding this comment.
This is a good idea. Let me think and ask some others about the naming as well.
Exposes the per-shot error model sparsification functionality added in #254 to the Python module and Sinter compatibility layer.
Changes:
sparsify_errors,sparsify_base_degree,sparsify_max_degree, andsparsify_reactivate_limit.tesseract.suggest_sparsify_reactivate_limit(num_detectors, sparsify_base_degree).sparsify_reactivate_limit == -1only when preparing the decoder.--sparsify-reactivate-limitis preserved, while omitted M is stored as-1until decoder initialization.--det-order-*method is specified.--det-order-bfsremains available for the old BFS behavior.TesseractSinterDecoderto support sparsification config while preserving pickle/serialization compatibility for existing distributed Sinter runs.tesseract-long-beam-sparsify3,tesseract-long-beam-sparsify2,tesseract-short-beam-sparsify3, andtesseract-short-beam-sparsify2.Verification:
bazelisk build --jobs=1 --local_resources=cpu=1 src:tesseractbazelisk test --jobs=1 --local_resources=cpu=1 //src:tesseract_tests